The present invention pertains generally to computer programs, and pertains more particularly to techniques for handling program objects in object-oriented programming.
In applications implemented by objected-oriented programming, elements of the application may be represented by programming structures known as program objects. A program object may represent essentially any real or imaginary, tangible or intangible item. For example, in a payroll system, an object may be used to represent an employee or an employee""s pay for a designated period of employment. In an aircraft landing control system, a program object may be used to represent individual aircraft or a particular runway. In this same system, a program object representing an entire airport could represent the control tower and also include or embed program objects representing all the runways for that airport.
Program objects normally do not survive beyond the execution lifetime of the program that creates them. The information that represents the objects normally resides in some form of volatile storage such as random access memory (RAM) and the ability to access and use this information normally exists only while the program that created the program objects is executing.
Known techniques allow an executing program to generate information that represents a program object in a form that can be recorded or transmitted, and that permit a program executing at another time or place to read the information and recreate the program object. Suitable techniques for program objects in the Java(trademark) programming language are disclosed in an xe2x80x9cObject Serialization Specificationxe2x80x9d published by Sun Microsystems, Inc. of Palo Alto, Calif. This specification is available from the Internet under a xe2x80x9cjdk-specification directoryxe2x80x9d identified by the Uniform Resource Locator (URL) http://java.sun.com/products/jdk/1.1/docs/guide/serialization/spec/. Under this jdk-specification directory, a table of contents for this specification is identified by xe2x80x9cserialTOC.doc.htmlxe2x80x9d and a discussion of system architecture is identified by xe2x80x9cserial-arch.doc.htmlxe2x80x9d. Additional information is available from articles published in JavaWorld by Web Publishing Inc. These articles are available from the Internet in subdirectories under a xe2x80x9cjavaworld directoryxe2x80x9d identified by the URL http://wwwjavaworld.com/javaworld/. The subdirectories and names for two relevant articles under the javaworld base directory are jw-01-1998/jw-01-beans_p.html and jw-02-1998/jw-02-beans_p.html. The term xe2x80x9cobject serializationxe2x80x9d refers to the process of generating a serial stream of information that represents a program object and the term xe2x80x9cobject deserializationxe2x80x9d refers to the process of reading the serial stream of information and recreating the program object.
Object serialization and deserialization can be used to optimize the processing required for one or more applications. For example, application processing can be split into segments and the processing required to perform those segments can be provided by two or more computing systems. One computer system could perform an initial segment of an application and, at the conclusion of that segment, serialize one or more program objects to capture the state of the processing in a serial information stream. A second computer system could continue application processing by recreating the program objects represented by the serial information stream, thereby restoring the state of the processing that existed in the first computer system at the end of the initial segment, and continuing the processing by performing a subsequent segment. Alternatively, serialized information could be provided to multiple computer systems for performing the same segment of the process more or less in parallel.
Unfortunately, known techniques for serializing and deserializing program objects impose significant restrictions on the changes that can be made to the programs used to perform an application. Changes that correct errors or add new features to an application may require corresponding changes in one or more defined structures of program objects. Each change to the definition of a program object is said to introduce a new xe2x80x9cversionxe2x80x9d of the program object. More precisely, such changes introduce a new version of the xe2x80x9cclassxe2x80x9d that defines the structure of a program object. A program object is an instance of the class that defines its structure.
A change may be forward compatible in the sense that a program using a later version of a class can successfully deserialize an instance of that class from serial information that was generated by a program using an earlier version of the class. A change may backward compatible in the sense that a program using an earlier version of a class can successfully deserialize an instance of that class from serial information that was generated by a program using a later version of the class. A compatible change is both forward and backward compatible. An incompatible change lacks either or both forward and backward compatibility. If a required change is incompatible, that change cannot be introduced into any one computer system until all computer systems that participate in a distributed network have been changed to use the same class version. Additional information about compatible and incompatible changes affecting program objects in the Java programming language may be obtained from the document xe2x80x9cversion.doc.htmlxe2x80x9d under the jdk-specification directory mentioned above, and from an article identified by jw-03-1998/jw-03-beans_p.html under the javaworld directory mentioned above.
Because changes to classes are generally incompatible, many known techniques for program object serialization automatically generate an identification of the class version that was in use at the time the program object was serialized. Examples of this technique are discussed in a web page under the base directory mentioned above. The subdirectory and name for this web page is jw-03-1998/jw-03-beans_p.html. This allows a program to check the version of the serialized program object against the current version of the class used to define new instances of objects. If the versions are not the same, an error or some form of program exception can be raised to alert the application program to the potential incompatibility.
If a change is known to be compatible, known techniques allow a class designer to override the automatic version identification feature by forcing the serialization process to generate the same version identification for a new class version that was generated for an earlier class version. This technique allows programs using different but compatible class versions to share serial information representing serialized program objects for that class. Unfortunately, no known technique allows programs using different and incompatible versions to share serialized information.
It is an object of the present invention to provide for the serialization and deserialization of a program object in a manner that permits programs to share serialized representations of program objects that are instances of incompatible versions of a class.
According to one aspect of the present invention, a method serializes a program object that is an instantiation of an object class by obtaining a version identification of the program object, and generating serialized information conveying a representation of the program object that is determined as a function of the object class and the version identification.
According to another aspect of the present invention, a method deserialize serialized information conveying a representation of a program object that is an instantiation of an object class by obtaining from the serialized information the object class and a version identification of the program object, and establishing values from the, serialized information for one or more properties of the object, wherein the values for the one or more properties are established as a function of the object class and the version identification.
These aspects of the present invention be implemented by an apparatus that is adapted to carry out the methods. They may also be implemented by a program of instructions conveyed by a medium readable by a device such as a computer system that can execute the programs of instructions.
According to yet another aspect of the present invention, a medium readable by a device conveys serialized information representing one or more program objects that are instantiations of an object class that comprises an indication of the number of program objects represented by the serialized information, an indication of the object class name, and for each respective program object represented by the serialized information, a version identification of the respective program object and a respective value for one or more properties of the respective program object.
According to a further aspect of the present invention, a medium readable by a device conveys one or more programs of instructions for execution by the device to perform a method for serializing or for deserializing a program object that is an instantiation of a program class. The one or more programs of instructions comprise a definition of the object class that includes a method for obtaining a version identification of a respective program object, and a definition of an object-descriptor class that includes a method for identifying one or more properties of the respective program object that are to be serialized or deserialized.
The various features of the present invention and its preferred embodiments may be better understood by referring to the following discussion and the accompanying drawings in which like reference numerals refer to like elements in the several figures. The contents of the following discussion and the drawings are set forth as examples only and should not be understood to represent limitations upon the scope of the present invention.